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Abstract- With companies continually striving to reduce 
cycle time, on tbe heels of significant gains, many are finding 
that further substantial improvement is difficult to achieve, 
especially on new (or breakthrough) products. This paper 
discusses factors influencing cycle time and means by which 
obstacles may be overcome to gain further advantages. 
Included are ways to gain competitive advantage by coupling 
product development and product portfolio strategy. The result 
is a new look at the trade off between the product portfolio and 
time to market. A benchmark study will be presented that 
demonstrates how product mix can influence cycle time. Once 
managers understand how their portfolios influence time to 
market, they have two possible approaches to explore. The first 
is a set of tools to analyze the portfolio as it relates to risk and 
development capacity. The second is a set of techniques 
especially suited for improving the cycle time of new products. 
Both approaches are recommended for a comprehensive 
solution to greater competitiveness. 

L Introduction 

This paper reviews the results of a study of rapid cycle 
time companies developing consumer electronics and OEM 
products. The study explores the practices of 13 
organizations as they relate to time to market factors. The 
companies' products are divided among "portfolio" 
categories, and time to market is measured for each class of 
development complexity (see Fig. 1). Portfolio balance is 
measured by identifying projects (either for new products or 
processes) as belonging to one of three categories of 
development: new, derivative, and variant, which are defined 
as follows: 

• New product: clean sheet of paper, platform 
product/process 

• Derivative product: new generation of an existing 
platform product/process 

• Variant product: a modification or line extension of an 
existing product/process 

The data indicate that average time to market is 
dependent on the portfolio mix and the time to market of 
individual classes of projects. Thus, time to market can be 
changed by adjusting the relative mix of products (and new 
processes) in your portfolio. A benchmark study and 
subsequent research highlights best practices in portfolio 
management based on proven applications in leading 
companies. Mapping products into these categories is the 
first step in gathering information that will enable 
organizations to make informed decisions about whether to 
consider adjusting the mix of products to optimize cycle time 
for specific new products. 

Changing the portfolio mix to achieve cycle time 
reductions may not be the best strategy from a business 
perspective. If it is not desirable to change the new product 
mix, what are the alternatives for reducing cycle time? Do 
these remedies vary as a function of product complexity? 
The short answer is yes. 



II. Product Development Cycle Time as a Function of 
Complexity 

This research is the result of a product development 
study aimed at understanding how fast the very fastest 
developers of electronic products are, and how they achieve 
their level of performance. Concluded in 1996, the study 
benchmarks 13 organizations (from 12 companies) 
universally known for short time to market. They consisted 
of 11 organizations from the U.S. and 2 from Japan 
representative of electronics manufacturers, including 
business to business office products, consumer products, and 
OEM products. 

Fig. 1 describes the time to market performance of these 
developers divided by the categories of complexity. The 
information is based on the internal definitions of the 
companies, which was adjusted to ensure comparability. In 
the cases cited below, time to market starts when 
management gives it's approval for the project based on 
some initial estimates of cost, schedule, and performance. 
The time to market ends at the point of first customer 
shipment. As can be seen from Fig. 1 below, these "fastest of 
the fast" performers develop new products in 27 months, 
derivative products in 12 months, and variant products in 
approximately 6 months. 
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Fig. 1 . Time to Market (in months) vs. Complexity 

However, these companies have different portfolios of 
complexity in their product development pipeline. As shown 
in Fig. 2, there is a large variance in the relative risk tolerance 
of these organizations as expressed in their product 
development plans. If an average were suggested, it might be 
that these developers choose to do about one in five products 
as new or breakthrough, and two in five as derivatives and 
variants. 

Several observations are in order. For example, doing 
more products in the new or breakthrough category should 
result in a shorter time to market in this class of companies, 
due to experience. On the other hand, those companies that 
do new products less frequently should experience a 
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development time longer than average for this class of 
products. This is the basis for our dilemma. 

Weighted time to market (WTTM) can be calculated by 
computing the weighed average of the products in a category 
times the relative frequency in that category. Thus WTTM is 
dependent on the portfolio mix and the time to market of 
individual classes of projects. This can be described as: 

WTTM - Sum (N p *TTM p + N d *TTM d + N V *TTM V ) 

The dilemma: Time to market can be changed by adjusting 
the relative mix of products in your portfolio. Should you 
consider adjusting the mix or should you optimize cycle time 
for the big, new products? 

Below is one example computed for Company "A" in 
Figures 1 and 2. Two calculations can be performed: first - 
reducing time to market by changing the mix; and second - 
reducing (weighted) cycle time by reducing the development 
time of the longest category, the new/breakthrough products. 

The portfolio mix of Company "A" is 40% new, 50% 
derivative, and 10% variant, with cycle time of 24, 8, and 6 
months respectively. Alternatives for reducing time to 
market are as follows: portfolio mix changed to 10%, 65% 
and 25% or new/breakthrough time halved to 12 months. 
These are shown in Fig, 3. 



III. What the Data Suggests 

This benchmarking study clearly demonstrates several 
principles. The first is that cycle time is not a monolithic 
metric, but a variable that depends on the cycle time of 
underlying projects of vastly different complexity. Second, 
the average cycle time can be modified in two ways - 
reducing the cycle time of the longest project (mainly 
breakthrough projects) or by changing the mix of products in 
development. It is unlikely the mix of projects in a portfolio 
will be changed for reasons of cycle time alone. However, 
this research does indicate that cycle time will be 
significantly influenced by the relative emphasis on 
new/breakthrough projects. 
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Fig. 3. Weighted Time to Market of company "A" as a function of time 
to market reduction method. The lowest bar is that of A without any 
changes, the middle bar shows the improvement possible by shortening 
the new/breakthrough time to market by a factor of 2. The top bar show 
the reduction by changing the mix to do fewer new/breakthrough 
products. 

The data also implies that companies that attempt to 
develop a large number of breakthrough projects should be 
able to reap the rewards of continuous improvement since 
they frequently are able to hone their skills. Now let's look 
at look at two ways of improving product development 
performance: changing the portfolio and reducing the cycle 
time of breakthrough products. 



IV. Best Practices to Manage Product Development 
Portfolios 

There are many ways to look at and modify the 
development portfolio to decrease cycle time and improve 
competitive outcomes. The development portfolio is defined 
as the relative mix of projects at the current time based 
typically on risk (or by objectives) and the size of the 
portfolio relative to the organizational (or financial) capacity. 
The more common techniques used for portfolio management 
include: portfolio maps (technology risk versus market risk), 
portfolio balance (percentage of products and processes that 
are classified as platform, derivatives, and variants), and 
portfolio size (the size in relation to the development 
capacity). 

One of the best ways to analyze product development 
portfolios is to map them against the variables of market and 
technology risk. Mapping can also be done against any other 
two dimensions (operational or supplier risks for example). 
This allows managers to allocate a rational investment to a 
given amount of risk and supposed return. Although there is 
no universally right portfolio mix, the mix must be congruent 
with corporate strategy and risk tolerance. For example, Fig. 
4 depicts the mapping between market and technology risks. 
This example is for a relatively risky portfolio. Often 
companies choose a "next square" approach which causes 
projects to be located off the diagonal of the figure. 

In addition, many managers choose to do as few new 
products as necessary to provide quantum leaps in 
performance. They use this as a "platform" on which to 
build derivatives and variants. While platform products may 
or may not pay back the initial investment, the follow-on 
derivatives, in general, are good investments and can be 
brought to market rapidly. 
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Fig. 2. Relative mix of portfolio (by project, not by effort) 
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Same New New customers 

customers customers and channels 

and channe Is or chaiwe Is 

Note: the area of each circle Is 
to the magnitude of development 

Fig. 4. An example map of a product portfolio showing a relatively 
risky portfolio (large investments in programs that are high technical 
risk and medium market risk). 

The second tool for process and product portfolio 
management specifically attempts to understand the variables 
that describe product and process risk (see Reference 2). This 
tool, was derived to manage the relative investments in process 
and product development. One of the most singular 
contributions of this analysis was to indicate that organizations 
often are too concerned by product and not enough by process 
(manufacturing, assembly, and fulfillment). In addition, it is 
used to help firms maximize the leverage obtained by creating a 
new product or process platform from which derivatives and 
variants can be developed. 

The third tool for technology management that can be 
very helpful to improvement of product development speed is 
correctly sizing the portfolio to the development organization 
size (see Reference 3). Far too often, organizations have too 
many projects under development at any given time. On the 
surface, this does not sound too harmful, in fact it sounds like 
the status quo. However, when an organization manages this 
way, it often finds that bottlenecks appear to have 
disproportionate impact on the development time. By 
reducing the number of projects under development and 
simultaneously eliminating the bottlenecks (by process 
improvements or increased investment), dramatic 
improvements in cycle time are possible. Tnis treatment 
borrows from operational research as applied to 
manufacturing and maps the implications of variance and 
queue time into the realm of product development. 



V. Best Practices to Reduce Cycle Time 

Despite the potential rewards, managers may want to 
leave the mix alone and look at other methods for reducing 
time to market. Studies have shown that the top two drivers 
of development schedule slips in new product development 
are (1) the poor definition of product requirements and (2) 
unanticipated technical difficulty (see Fig. 5). Fig. 5 
illustrates the relative frequency of these two drivers for late 
projects. 

Based on our client research, these two items often have 
the biggest impact for the new/breakthrough products. These 
two areas especially plague the new/breakthrough program 
because the best project managers are assigned, they are 
given the highest organizational support, the resources they 
need, and top management attention. 




Fig. 5. Analysis of the causes for product development delays 
(Reference 4). 



Market-Driven Product Definition (MDPD) is an 
effective best practice aimed at reducing the delay (or 
ensuring that you don't miss the market) in 
new/breakthrough products. This technique has several 
merits. It is a systematic process for obtaining customer 
needs that takes the project team from start (the idea phase) 
to the end (generation of product specifications) of the early 
part of a project. It also combines "narrow and deep" aspects 
of requirements understanding (i.e., customer visitation by 
the core development team) in the environment of use. The 
flow of the process is shown in Fig. 6. 




Fig. 6. Market-Driven Product Definition flow diagram for deep 
understanding of the customer's requirements. (Reference: Product 
Development Consulting, Inc.) 

Market-Driven Product Definition is a tool that can help 
manage the robust definition of product requirements and 
clarify the so called fuzzy front end of development. MDPD 
is a comprehensive framework for defining products which 
integrates many best practices. The process breaks down into 
roughly five phases: 

1. Gather Customer Information: This stage involves 
gaining a common vision of your customer's 
environment via customer visits by cross-functional 
teams. 

2. Develop Customer Requirements: During this stage, the 
team converts the vision into a set of requirements. 

3. Develop Metrics for Requirements: This stage is based 
on the development of a measurement for each 
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requirement for both competitive analysis and for 
downstream test requirements. 

4. Validate and Prioritize Requirements: This stage is 
designed to foster team understanding of the priorities of 
the proposed product attributes. 

5. Generate Product Definition: Finally, the team arrives at 
a product definition specification. 

The visits typically are held with 12-24 customers, 
~ spending approximately one day with the customer. The 
visits are never combined with selling or problem solving. 
This provides profound understanding of the requirements 
that the marketing representative could never convey to the 
team (steps 1 and 2). Furthermore, MDPD also uses "broad 
and shallow" techniques (the use of survey techniques - steps 
3 and 4) to validate the requirements. Thus it is a robust 
process that ultimately delivers a stable and robust product 
definition (step 5). 

The second best practice, which is oriented towards 
minimizing technology risks, is a derivative of the Motorola 
Roadmap process (Reference 5). The Technology Roadmap 
is a graph linking expected technology implementations to 
dates and specific products. It is a major component in 
Motorola's project planning process. This can reduce cycle 
time because technologies are developed "off line" so that 
they can be proven in the laboratory before they are handed 
off to development. Explicit "hand-off or deployment from 
technology planning to product developers ensures that the 
appropriate technology is incorporated into products. 

In a prior study conducted in 1995, it was found that this 
(or a similar best practice is used by about 2/3 of the 
exemplars studied (Reference 6). They use an explicit 
process for projecting technology trends in their critical 
technologies "often" or "exclusively". 



VI. Summary 

Overall, these studies highlight the importance of 
characterizing development projects into different 
classifications for purposes of: 1. portfolio management, 2. 
improvement methods, and 3. benchmarking comparisons. 
Without a clear understanding of the fundamental differences 
between projects of differing complexity, an organization is 
unable to optimize its process. Furthermore, these studies 
indicate the value of managing the portfolio not only for market 
return, but also from the perspective of the development 
process. 

The tools described provide a framework to make trade off 
analyses that examine the impact the portfolio can have on cycle 
times for individual projects and for the portfolio as a whole. In 
addition, it is essential that one optimize the portfolio based on 
risk tolerance, development capacity, and product life cycle. 

Finally, if an organization is going to work on cycle time 
reduction for platform projects, it may wish to consider Market- 
Driven Product Definition to secure high quality requirements, 
and a technology roadmap process to develop technologies "off- 
line." Reducing cycle time for different classes of complexity 
will involve different strategies. 
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